home *** CD-ROM | disk | FTP | other *** search
- Portal-Rmail-To: garyt@cup.portal.com
- Received: by portal.com (3.2/Portal 8)
- id AA13166; Wed, 26 Apr 89 01:38:31 PDT
- Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
- id AA18573; Tue, 25 Apr 89 23:08:58 PDT
- Received: from sun by Sun.COM (4.1/SMI-4.0)
- id AB12617; Tue, 25 Apr 89 23:08:11 PDT
- Message-Id: <8904260608.AB12617@Sun.COM>
- Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5946; Wed, 26 Apr 89 02:02:49 EDT
- Received: by LEHIIBM1 (Mailer R2.03A) id 5722; Wed, 26 Apr 89 02:02:45 EDT
- Date: Wed, 26 Apr 89 02:02:44 EDT
- From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
- Subject: File: "V101 3" being sent to you
- To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>
-
- Subject: Virus 101: Chapter 3
- From: woodside@ttidca.TTI.COM (George Woodside)
- Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
- Date: 13 Mar 89 14:24:23 GMT
- Reply-To: woodside@ttidca.tti.com (George Woodside)
- Organization: Citicorp/TTI, Santa Monica
-
- First, the mail:
-
- Addressing a controversial topic is sure to generate some strong responses,
- and this one is no exception. Mail of the "Thank You" flavor outweighs the
- "You Idiot" flavor by about 4-1, so I'll be pressing on. The majority of the
- "You Idiot" mail is from senders who either admit, or display, limited
- programming ability. For the benefit of those individuals: I appreciate your
- concern. I am not attempting to aid in the spread of viruses, but in your
- own understanding of them, and ability to defend yourself. People with the
- ability to create a working virus will have found little or nothing they
- didn't already know in the preceeding postings. There is certainly nothing
- in them that isn't already available in the most fundamental books about
- personal computers. The preceeding postings are also written at a
- superficial level, and are missing quite a few specific things necessary to
- make a real working virus. Those missing items would add nothing to the
- layman's understanding of how a virus spreads or works, so are not included.
- You need not take my word for this; contact anyone you know who is
- knowledgeable in the system software field, and they will confirm it.
-
- Sin of omission:
-
- Part of a message received from Forrest Gehrke (feg@clyde.att.com):
-
- ...One method for a virus finding enough space to hide itself, that I have
- seen, you have not mentioned. I have noticed that the so-called Pakastani
- virus uses non-standard sectoring at tracks 37 and 38 for IBM PC
- diskettes...
-
- Mr. Gehrke is quite right. I did forget to mention this technique. While I
- had heard rumors of it being in use, I hadn't seen it in any of the virus
- code I've captured (again, I'm in the Atari ST world).
-
- I have responded to all mail I have recieved (if it requested a response)
- including mailing out copies of missed chapters. Several responses have been
- returned by various mailers. If you requested something, and haven't heard
- from me, either your request or my response failed.
-
- Now, Chapter 3:
-
- Once a virus has installed itself, and replicated as frequently as it has
- found the opportunity, it will eventually launch whatever form of attack it
- was originally designed to do. That attack is the real purpose of the
- existance of the virus. Everything up to this point has been for the sake of
- getting to this stage.
-
- What will it do? Almost anything. The limits are imagination and code space.
- The most benign virus I've seen claims to be an anti-virus. It blinks the
- screen on boot-up. The idea is that if you see the screen blink, you know
- that the benign virus is on the disk, rather than a more malicious one. It
- does, however, spread itself just like any other virus. From there, things
- proceed through the prank levels, time-triggered, messages, ones which try
- to simulate hardware failures, to ones which destroy files and disks. The
- actions vary from virus to virus. And, of course, there is a whole different
- library of viruses for each machine type. Attempting to detect a virus by
- describing or recognizing the symptoms is not only a task of limitless
- proportions, it is too little too late. When the symptoms appear, the damage
- has already been done.
-
- Several viruses attempt to simulate hardware problems. (Conversly, I've had
- several pleas for help with a virus that proved to be other types of
- failures.) Frequently these viruses use timers to delay their actions until
- the system has been running for some time, and to spread out their
- activities to make the problem appear intermittent. Such virus induced
- glitches include occasionally faking succesful disk I/O, while actually not
- performing the read or write, altering the data being read or written, and
- (more commonly) screen display glitches. It is very difficult for anyone to
- determine whether such incidents are the results of a virus, or a real
- hardware problem. When such incidents start to occur on your system, start
- executing whatever virus detection software you have available, before
- lugging your system off to a service firm.
-
- Previously, I mentioned the use of write protected disks as a step in the
- right direction to protect yourself. A large percentage of personal computer
- systems now use hard disk systems. Floppy disks are more often a backup
- media, or offline storage of files not needed on the hard disk for day to
- day use. Backing up requires the disks to be writeable, as does archiving
- off the infrequently used files. It is good practice to write protect the
- archived disks as soon as the files are copied to them. Run whatever virus
- checking software you have on the archive disks, write protect them, and
- then file them away.
-
- (When reading the following suggestions about protecting your system from
- attacks, keep in mind that not all techniques can be applied to all systems
- or all software. Read the documentation accompanying the software before
- your first attempt to use it. Be familiar with what it is expected to do
- before you run it, and you'll be more able to recognize unexpected activity.)
-
- The next step is to apply write protection to whatever disks you recieve
- software distributed on, before ever inserting them into a computer. Be they
- Public Domain, User Group Libraries, Commercial Software, or whatever, write
- protect them before you first read them. Then, make a backup copy if
- possible. Finally, when first executing the new software, have only write
- protected disks in your system. You should be well aware of any legitimate
- attempt to write to a disk by the software before it happens, and have
- adequate opportunity to insert a writeable disk when the proper time comes.
- This will not only give you a clue to the presence of a virus in the new
- software, but also protect the new software from a virus already resident in
- your system.
-
- If your system supports the use of a RAM disk, copy new software into the
- RAMdisk before executing it the first time. Put write protected disks in
- the drives, then execute the software from the RAMdisk. If the software has
- no reason to access other disks, especially when starting itself up, be
- very suspicious of any disk activity. The most common time for a virus or
- trojan horse program to do it's dirty work is at startup, when it is
- impossible to tell whether disk access is part of program loading, or some
- clandestine operation. By having the software loaded into and executing
- from memory, you will be able to detect any disk I/O which occurs.
-
- Finally, backup everything. Hard disks, floppy disks, tapes, whatever. Make
- backup copies, write protect them, and store them in a safe place off-line.
- If you are attacked by a dstructive virus, your first problem is to rid your
- system of the virus. Do not go to your off-line backups until you have
- determined if your problem came from a virus, and if so, that you have
- removed it from the system. A backup is useless if you give a virus a chance
- to attack it as well as your working copy.
-
- A significant portion of these three chapters have been related to boot
- sector viruses. While the most common type in the Atari and MS-DOS world,
- they are certainly not the only type.
-
- What follows is next is mostly a re-phrasing of an article from "Los Angeles
- Computer Currents", June, 1988. There are a few direct quotes from the
- copyrighted article. While I do not agree with all that this article states,
- I can not disprove the items from a position of experience. Since my efforts
- here are to inform, you may judge for yourself. A significant portion of my
- remarks are oriented to the Atari ST, but the concept is true to most all
- personal computers.
-
- An article in that issue, by Lewis Perdue, outlined the problems he faced
- when the IBM PC running Ventura Publisher he was using to create the first
- issue of PC Management Letter became infected. I won't begin to copy all
- that, but the most interesting part of the recovery task was when they used
- a normal (high-level) format program to clear the hard drive. It didn't kill
- the virus. They had to resort to a low level format, and rebuild from all
- original distribution disks. Their backups had been infected as well as
- their working copies of the software. They relied on a PC specific tool
- called Data Physician, by Digital Dispatch, to aid in the detection of the
- virus. It implements techniques to diagnose infections, but it has to be
- installed before the virus strikes.
-
- Another, more interesting aspect of the article, was categorizing viruses
- into four groups: Shell, Intrusive, Operating System, and Source.
-
- Shell - these "wrap themselves around a host program and do not modify the
- original program." In laymen's terms, such a virus would tack itself onto a
- program file, so it would get loaded with the program. It would have to do
- this in a manner that would cause itself to be executed before the host,
- since the host certainly would not pass control to the virus.
-
- This would be quite a complex task on an Atari ST (and on systems with a
- similar structure for executable program files). The virus program would
- have to be quite large in order to deal with the structure of an executable
- file on the ST. In simple terms, an executable file (a program) is a series
- of unique sections: a header, the code, data, a relocation map, and possibly
- a symbol table. The header specifies the size of each of the following
- segments. The code is the program, but in a form which will not run until it
- has been relocated. The data is constants, literals, messages, graphic data,
- etc. The relocation map tells the ST what changes to make to the code before
- it can be run. The symbol table is not usually present, except during
- program development. The reason behind this structure is that when a program
- is created, it does not know where in memory it will reside when it is
- executed. Things like RAMdisks, device drivers, accessories, printer
- buffers, spelling checkers, and so on, may or may not be present in the
- computer when the program is run. Since each of those things require memory,
- the place where the program will wind up being loaded is unknown. So, when
- it does get loaded, it has to be told where it is. And, since the program
- will almost always contain references to itself (subroutines, variables,
- etc.) it has to be modified so that those references point to the right
- place. That's what the relocation map is for. It details how the program has
- to be modified. Once the program is loaded into memory, and fixed up, the
- relocation map and symbol table are discarded. So, to hook into a program
- file, a virus would have to split the program file, attach itself to the
- beginning of the code segment, (that's where execution begins), re-attach
- the data, relocation, and (possibly) symbol table segments, update the
- relocation map (all the original references would now have moved), update
- the header, then re-write itself to the original disk, assuming there was
- room on the disk for the (now bigger) file and that the disk was not
- write-protected. That's a large amount of work to develop, and a large
- amount of code to sneak into a system for the original infection.
-
- I should mention here that it is not difficult to write "position
- independant" code on most micro-processors. You have to set out to do that,
- though, and take the necessary steps along the way to keep everything
- position independant. Boot sector code is a well known example. The address
- where the boot sector will be loaded into memory is unknown, and there is no
- relocation done on the code. It has to be position independant. It also has
- to fit in the boot sector. If it needs more than the amount of space in the
- boot sector, it has to determine its own location, and load the additional
- code itself. Of course, that means that it had to have a place to store the
- additional code, and it had to know where to find it. Those items were
- covered previously.
-
- Detecting a "Shell" type virus is not difficult. When it attaches itself to
- the target program, it must increase the size of the file. While it would be
- a real nusiance to check file sizes on a regular basis, there are programs
- available to do this for you. An "alteration detection" program will
- typically accept a list of programs to recognize. It will write a data file
- of its own, noting characteristics of each file in the list, such as length
- and date, and then run a numeric algorithm across the file. The numeric
- algorithm (typically a Cyclic Redundancy Check, or CRC) will yield a value
- which is stored in the alteration detection program's own data file. Then,
- on each subsequent execution of the alteration detection program, it checks
- the recorded characteristics of each file in its list, and re-executes the
- algorithm on the files. It reports back any file which has been changed
- since it last executed. Needless to mention, such a program must be run on
- the files to be monitored before any virus has an opportunity to attach
- itself to those files. Then, it must be run frequently to have a chance to
- detect altered files.
-
- (Back to the types of viruses defined in the article)...
-
- Intrusive - Intrusive viruses work by patching themselves into an existing
- program. This type of virus has two possibilities - either it is willing to
- render the host program useless, or it will attempt to co-exist with the
- host. If it is willing to corrupt the host, this is not too difficult a
- task. It would replace a part of the host program, modify the relocation
- map, and wait to get run. When it did, it would abandon the original task of
- the host program, and launch its attack. An example of this would be the
- virus bearing version of a word processor which struck the IBM compatible
- market some years ago. It signed on, looking just like a popular shareware
- program, but it was busy re-formatting the hard disk while the user waited
- for it to load and get ready to accept input.
-
- The other flavor of intrusive virus, which attempts to co-exist with the
- host program, is terribly difficult to create. It has to modify the host in
- a manner that either accomplishes the host's task while also doing it's own,
- or find a part of the host that is infrequently or no longer used, and hide
- there. It would then have to modify some other part of the host in order to
- get itself executed. In either case, a virus of this type has to be aimed at
- one specific host program. There's no way it could perform the analysis
- necessary to locate such portions of a randomly selected program. For that
- reason, an intrusive virus has to target some program that resides on a
- large portion of the target computer's installations, and that it is certain
- will be available to tamper with when the virus introduction occurs. That
- normally means either the Operating System, or some utility program so
- common that it is found virtually every where.
-
- Operating System viruses work by replacing a portion of the Operating System
- with their own code. This is similar to the intrusive type, except that it
- can use a new trick (and there are ones that do this on the IBM/MS-DOS
- computers). As a part of the operating system, it can sneak out to a hard
- disk, find an unused part, mark it as defective, and hide there. That would
- mean only a very small part of the code would have to be hooked into the
- operating system (possibly as an entry in a list of device initializing
- routines). That small segment could then allocate adequate memory for the
- real routine, and load it from wherever.
-
- Source Code viruses - I found this type of virus to be a bit unbelievable.
- The article reads (I quote):
-
- Source code viruses are intrusive programs that are inserted into a
- source program such as those written in Pascal prior to the program
- being compiled. These are the least-common viruses because they are
- not only hard to write, but also have a limited number of hosts
- compared to other types. (end quote)
-
- Sounds to me like this would be nearly impossible to accomplish in
- after-market software. If, on the other hand, they mean a part of the
- program added by a devious member of a development team, then, it is
- credible. It brings to mind the story (which I can't verify, but I've heard
- it from enough different sources to believe it is true) about what may well
- have been the first virus. In case you're not familiar with "C" compilers,
- they are usually several different programs, which must be run in proper
- sequence, passing files and options from one to the next. Usually, this is
- all done by a another program, a "compiler driver", which is almost always
- called "cc". You execute "cc", passing it the necessary flags, and the
- name(s) of the program(s) you want compiled, and it drives all the necessary
- tasks to do it.
-
- This was reported to have been done by one of the originators of the UNIX
- operating system, (name deleted), back in the development days at Bell Labs.
- Well, the story goes, he wrote the first versions of UNIX, "C", and "cc". He
- had a "back door" to get into a system running UNIX. He built the back door
- code into "cc". The code in "cc" checked to see what it was compiling. If it
- was the module "login", it incorporated the back door into the module, so
- that he could get into the system. If, on the other hand, it was compiling
- "cc", it included the code both to re-create itself, and the code to build
- the back door into "login". So, every "cc" had the code, and consequently
- every UNIX system included the back door. Eventually, it was discovered, and
- removed. There followed a frantic rebuilding of every UNIX system in
- existance, so the story goes.
-
- This is the final chapter which will be distributed via cross-posting.
- Chapter 4 will relate specifically to viruses captured in the Atari ST
- environment, and will be posted only to comp.sys.atari.st. It will come out
- about 1 week after this one. This article was posted on March 13, 1989, so
- you can determine the approximate delay to your receipt, in case you don't
- read that newsgroup, but wish to locate the fourth chapter in
- comp.sys.atari.st.
-
- End of Chapter 3.
-
- --
- *George R. Woodside - Citicorp/TTI - Santa Monica, CA
- *Path: ..!{philabs|csun|psivax}!ttidca!woodside
-